JUN-01-2004 TUE 02:06 PM TROP, PRUNER & HU, PC FAX NO. 7134688883 



P. 08 



Appl. No. 09/465,629 

Amdt dated June 1, 2004 

Reply to Office Action of March 30, 2004 

REMARKS 

In the Office Action dated March 30, 2004, claims 1-4, 8-15, 17-21, 24-28, 35 and 
36 were rejected under 35 US.C. § 103 over U.S. Patent No. 6,055,236 (Nessett) in view 
of D. Maughan, entitled "Internet Security Association and Key Management Protocol 
(ISAKMP)," RFC 2408 (November 1998) (Maughan). 

Independent claim 1 recites a method of routing a data unit that comprises 
receiving the data unit, the data unit including ISAKMP security information and address 
information* The method further comprises translating the address information to an 
address of a target network entity based on the ISAKMP information. 

Nessett teaches distributed network address translation with security. When 
sending an outgoing packet, a local network device adds an outer or tunneling IP header 
that contains the internal network address of the source network device and an internal 
network address of a router on the local network. Nessett, 1 5 :42-66. When the router 
receives the outgoing packet, the router 26 of Nessett removes the outer header and 
forwanis the remaining packet to the external network, Nessett, 32:41-49. Note that the 
router 26 strips the outer header from the packet before forwarding it to the external 
network-the router 26 does not translate the address in the outgoing packet. Similarly, 
for an incoming packet from the external network, the router 26 constructs the outer 
header or tunneling header and adds the outer header to the incoming packet. Nessett, 
32:56-60. The outer header contains the source local network address of the router 26 
and the destination local network address of the local network device. The packet is 
forwarded to the local network device, which removes the outer header and processes the 
packet. Nessett, 32:60-62. "Thus, the router 26 does not modify contents of a received 
IPsec packet" Nessett, 32:63-64. In other words, the router 26 of Nessett does not 
perform translation of address information included in a received data unit (which would 
involve modifying the content of the data unit)* Instead, the router 26 of Nessett strips an 
outer header from an outgoing packet, and adds an outer header to an incoming packet. 
Translation of the address information contained in the data unit is avoided by the 
distributed network address translation scheme of Nessett. 
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Distributed network address translation as performed in Nessett is distinguished 
from regular network address translation. As discussed in Nessett, a problem of regular 
network address translation is that it interferes with the end-to-end routing principle of 
the Internet that recommends that packets flow end-to-end between network devices 
without changing the contents of any packet along a transmission route. Nessett, 1 :60-65. 
Also, translating between a local network address and an external network address at a 
router is computationally expensive, and causes security problems. Nessett, 2:1-10* In 
fact, computational burdens placed on a network address translation router may be 
significant and may degrade network performance. Nessett, 2:20-22. To avoid network 
address translation by the router, the distributed network address translation arrangement 
is proposed by Nessett, which adds an outer or tunneling header to a paeket, with the 
outer or tunneling header containing internal network addresses to enable communication 
between network devices on an internal network. Before a packet is transmitted to an 
external network, this outer header is stripped. The stripping and addition of an outer 
header containing local network addresses do not constitute translating the address 
information of a received data unit, as recited in claim 1 . 

In view of the foregoing, it is respectfully submitted that even if Nessett can be 
properly combined with Maughan, the asserted of combination of references does not 
disclose or suggest all elements of claim 1 . Therefore, a prima facie case of obviousness 
has not been established for at least this reason. 

Moreover, there is simply no motivation or suggestion to combine Nessett and 
Maughan in the manner proposed by the Office Action. Nessett actually teaches away 
from the claimed invention, since Nessett teaches that translating of address information 
in a received data unit is undesirable because it is computationally intensive and poses 
security problems. Rather than perform translation of address information in a received 
data unit, the distributed network address translation scheme described by Nessett 
involves stripping and adding an outer header to outgoing and incoming packets, 
respectively, by the router 26. Because Nessett teaches away from the claimed invention, 
there is not motivation or suggestion to combine the teachings of Nessett and Maughan. 

Moreover, Nessett is simply silent on any teaching of using ISAKMP information 
to perform address information translation, as recited in claim 1 . Although Nessett 
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describes a way to map an SPI value (of an ESP header) to a local IP address (using the 
mapping information of Figure 21), there is no teaching or suggestion whatsoever that a 
similar mapping can be performed between ISAKMP information and the local BP 
addresses. To perform this mapping between ISAKMP information and network 
addresses, the presence of initiator and responder cookies according to ISAKMP are 
typically used. Nessett does not even mention the initiator and responder cookies of the 
ISAKMP security information. Although the ISAKMP specification in Maughan 
describes ISAKMP information in great detail, including the initiator and responder 
cookies of the ISAKMP security information, there is no suggestion whatsoever in 
Maughan of using the ISAKMP information to perform address translation. Thus, what 
the Office Action has performed is a classic example of using impermissible hindsight to 
combine reference teachings by picking and choosing isolated elements from the 
individual references to achieve the claimed invention, where no motivation or 
suggestion existed to combine the reference teachings. 

In view of the foregoing, it is respectfully submitted that a prima facie of 
obviousness has not been established with respect to claim 1 for the further reason that 
there is no motivation or suggestion to combine the teachings of Nessett and Maughan. 

Independent claim 26 is similarly allowable over the asserted combination of 
Nessett and Maughan, Claim 26 recites receiving a data unit having ISAKMP security 
information and a destination address, accessing one or more translation tables each 
containing ISAKMP information and an address of a network entity and converting the 
destination address of the data unit to the network entity address based on the ISAKMP 
information and the address in the one or more translation tables. In Nessett, as discussed 
above, the stripping and adding of an outer header to outgoing and incoming packets by a 
router does not constitute converting a destination address as performed in claim 26. 
Therefore, even if combined, the asserted combination of Nessett and Maughan fails to 
teach or suggest the claimed invention. 

Moreover, as discussed above, there is no motivation or suggestion to combine 
Nessett and Maughan for the reason that Nessett teaches away from the claimed 
invention, and further, there is nothing within Nessett or Maughan to suggest to a person 
of ordinary skill that conversion of a destination address can be based on ISAKMP 
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information. Therefore, a prima facie case of obviousness has not been established with 
respect to independent claim 26. 

Independent claim 28 is allowable over the asserted combination of Nessett and 
Maughan for reasons similar to those given for claims 1 and 26. 

With respect to independent claim 1 1, neither Nessett nor Maughan teaches or 
suggests a translator to generate an identifier of a network entity that a data unit is 
targeted for based on IS AKMP information. As noted above, although Nessett describes 
a router that maps an SPI value to local network addresses, there is absolutely no mention 
whatsoever of using IS AKMP information to map to a local network address. Although 
Nessett describes using 1SAKMP to perform security association negotiation, Nessett 
does not provide any teaching that a translator can generate an identifier of a network 
entity that a data unit is targeted for based on ISAKMP information. Maughan fails to 
provide any suggestion of using ISAKMP information to enable a translator to generate 
an identifier of a network entity that a data unit is targeted for. Therefore, even if the 
references are combined, the hypothetical combination of references does not teach or 
suggest all elements of claim 1 1 . 

Moreover, there simply is no motivation to combine the teachings of Nessett and 
Maughan. Nessett is completely silent on the use of ISAKMP information, especially 
initiator and responder cookies, to enable mapping to an identifier of a network entity that 
a data unit is targeted for. Although the presence of initiator and responder cookies 
would have been known to persons of ordinary skill in the art, such cookies have been 
primarily used for the purpose of establishing security associations for secure connections 
between network devices. It is the inventors of the present application that recognized 
that the ISAKMP information can be extended for use with other pmposes, in particular 
for use by a translator to generate an identifier of a network entity that a data unit is 
targeted for. It is therefore submitted that no motivation or suggestion existed to combine 
the teachings of Nessett and Maughan. A prima facie, case of obviousness has thus not 
been established with respect to claim 1 1 . 

Independent claims 20 and 27 are allowable for reasons similar to those for claim 

11. 
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Dependent claims are allowable for at least the same reasons as corresponding 
independent claims. 

The Commissioner is authorized to charge any additional fees, including 
extension of time fees, and/or credit any overpayment to Deposit Account No. 20-1 504 
(NRB.0007US). 



Respectfully submitted, 



Date: Tune 1. 2004 




Dan C. Hu, Reg. No. 40,025 
TROP, PRUNER & HU, P.C. 
8554 Katy Freeway, Suite 100 



Houston, TX 77024 
713/468-8880 [Ph] 
713/468-8883 [Fax] 
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